• Toda revisão deve ser comentada para facilitar o entendimento das alterações realizadas;
• O código no trunk deve sempre estar pronto para ser compilado e colocado em produção se necessário. Nesse sentido, uma ferramenta de integração contínua, como o CruiseControl, deve ser utilizada para a geração de builds de teste a cada commit e todas as noites ao longo da semana;
• É dever de cada programador assegurar que seus commits não causem a quebra do build. Novamente uma ferramenta de integração contínua pode auxiliar nesta tarefa;
• As alterações em um código-fonte devem ser submetidas ao repositório o mais rápido possível. Para tal, é recomendável a divisão das implementações em pequenos pacotes compiláveis e funcionais ou, ao menos, que não causem a quebra do build. Quanto mais tempo um arquivo mantém-se na máquina de um desenvolvedor em edição, mais difícil será sua mesclagem e maior será o risco de quebra de build;
• Toda a quebra de build deve ser tratada com máxima prioridade no sentido de sua correção. Mais uma vez uma ferramenta de integração contínua pode auxiliar nesta tarefa;
• Caso um build esteja quebrado, não se deve submeter alterações ao repositório até que o build seja novamente compilável. Isso assegura que todos os que realizarem updates terão sempre uma versão compilável e funcional oriunda do repositório;
• O projeto no repositório deve conter quaisquer componentes e ferramentas necessárias para o funcionamento da aplicação na máquina do desenvolvedor;
• Evitar o envio de alterações próximo do fim do expediente. Caso haja algum problema com o commit realizado, poderá não haver tempo para corrigi-lo naquele dia e o build poderá ficar quebrado por um longo período;
• Todo e qualquer backup de versões deve ser mantido no repositório, preferencialmente como uma tag.

Adaptado de Subversion.